REMARKS 

The application originally included claims 1-38. The applicants affirm the election made, 
without traverse, via telephone conference on 5/20/08, of claims 1-9 and 21-38 for immediate 
prosecution. Accordingly, for purposes of this amendment, claims 10-20 are withdrawn. 

The applicants amend claims 1, 2, 5, 21, 22, 25, 30, 31, and 34. This amendment is made 
under 37 CFR 1.1 14(c) providing that an amendment fulfills the requirements of a "submission" 
as needed to file a Request For Continued Examination (RCE). A completed RCE transmittal 
form (PTO/SB/30EFS) is submitted herewith. Also submitted herewith is a payment 
authorization form (PTO/SB/17) authorizing payment of the one-month extension fee. 

The applicant's cancel claims 6, 26, and 35. The application remains with claims 1-5, 7-9, 
21-25, 27-34, and 36-38 after entering this amendment. 

The applicants do not add new matter and request reconsideration. 

Claim Objections 

The examiner objected to claims 21-29 for informalities. The alleged informality, 
wherein independent claim 21 , line 3, referred to "the same priority" instead of "a same priority" 
is moot in light of the claim amendments. 

Claim Rejections - 35 U.S.C. § 112 

The examiner rejected claims 1-9 and 21-38 under 35 U.S.C. § 1 12, first paragraph as 
failing to comply with the written description requirement. In particular, in claim 1 as previously 
written for example, the phrase "same priority value" was allegedly not described in the 
specification. 

The claims have been rewritten to more explicitly describe what was previously referred 
to as the "priority value." Referring to amended claim 1 , for example, the term "priority 
indicator" is used. This priority indicator is such as to be provided by actual media payload 
packets "to specify a desired one of a plurality of priority levels available in the network" for 
those packets. Also this priority indicator is provided "at a protocol layer other than that of the 
application protocol." Examples of this priority indicator are given in applicant's original 
specification, on page 5, lines 11-12, and include the Differentiated Services Code Point (DSCP) 
bits or the Class of Service (COS) bits. The DSCP bits, for example, represent the first six bits 
of the field labeled "Type Of Service" in applicant's original Fig. 4 and serve as one form of 
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"priority indicator." as claimed. Applicant would note that there is no requirement that the 
language in the claims exactly repeat (in haec verba) the language in the specification. 1 
Claim Rejections - 35 U.S.C. § 103 
Before considering the specific rejections lodged against the claims in the Action dated 
May 22, 2008, it is first noted that using tracer packets with incrementing Time-To- Live values 
to identify intermediate nodes along the end-to-end path taken by the tracer packets is known in 
the art (e.g., see applicant's original disclosure, page 1). Conventionally, User Datagram 
Protocol (UDP) packets are used (see applicant's original disclosure and Aggarwal et al., U.S. 
Pat. No. 5,675,741). Selvaggi et al, U.S. Pat. App. Pub. No. 2004/0193709, the primary 
reference relied on in the Action, adds the idea of using real-time transport (RTP) packets as the 
tracer packets where these RTP trace packets emulate a conventional RTP packet by 
"simulating" Voice-over-Internet Protocol (VoIP) traffic in their payload (Selvaggi et al., par. 
0054). This is done because "using data packets other than VoIP packets" (e.g., UDP packets) 
"may not accurately depict the path that VoIP traffic will take through the network" (Selvaggi et 
al., par. 0054). 

In the Action dated May 22, 2008, the examiner rejected claims 1-7, 9, 21-27, 29-36, and 
38 under 35 U.S.C. § 103(a) as being unpatentable over Selvaggi et al. (hereafter, simply 
Selvaggi). The examiner rejected claims 8, 28, and 37 under 35 U.S.C. § 103(a) as being 
unpatentable over Selvaggi in view of Alberth et al. (U.S. Patent Application Publication No. 
2004/0125965). These claims will now be considered, in turn, below. 

Independent claim 1 

In respect to claim 1 , the Action alleges that although Selvaggi does not disclose the 
claimed operation of assigning a same priority value to "media trace" packets and "actual media 
payload" packets, this operation would have been obvious so that these two different packets are 
provided "the same quality of service" in order "to ensure the equal treatment" of the two packet 
types in the network. In a general sense, it is true that Selvaggi seeks to obtain what the 
examiner terms "equal treatment" for its two packet types, that is, for its RTP "traceroute" 

1 See M.P.E.P. § 2163.02; In re Smith, 481 F.2d 910, 914; 178 USPQ 620 (CCPA 1973); and In re Barker and 
Pehl, 559 F.2d 588, 194 USPQ 470 (CCPA 1977). Applicant would further note that the examiner has the initial 
burden of presenting evidence or reasoning to explain why persons skilled in the art would not recognize in the 
original disclosure a description of the invention defined by the claims. See M.P.E.P. § 2163 II 3(b) and 
Wertheim, 541 F.2d 257, 263; 191 USPQ 90, 97 (CCPA 1976). 
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packets and for conventional RTP packets that actually carry media data such as VoIP data. 
However the way in which Selvaggi goes about achieving this "equal treatment" is very different 
than that claimed, and the result Selvaggi achieves is less than satisfactory. 

Selvaggi "s RTP traceroute packets are given a dummy payload that "simulates" VoIP 
data "because routers may treat packets differently depending on their payload" (Selvaggi, par. 

0054) . This last quoted statement is not entirely correct and may lead to undesirable playback 
effects at the destination receiver. Selvaggi also requires that the network be reconfigured to 
include "performance nodes" capable of supporting its RTP traceroute operations (Selvaggi, par. 

0055) . For example, Selvaggi teaches reconfiguring the network using an "rtp priority" 
command (Selvaggi, par. 0075). 2 Such a network command tells the node(s) that they are to give 
absolute priority to RTP packets over all other types of packet traffic. 3 This is how Selvaggi 
ensures that its RTP "traceroute" packets are given "equal treatment" as Selvaggi's conventional 
RTP data packets. In effect, Selvaggi enables the user to accurately measure network 
performance provided that the network is first configured to include only such performance 
nodes. The embodiment of amended claim 1, in contrast, describes an approach for analyzing a 
network in which the processing devices (e.g., routers) along the media path do not need to be 
reconfigured or artificially constrained in this manner. 

Referring now to claim 1, as amended, describes a method for "analyzing a media path" 
in a packet switched network. In accordance with this method, "media trace" packets are 
provided "configured to use the same application protocol" as the "actual media payload" 
packets to be sent along the media path. For example, if the "actual media payload" packets are 
to be sent using the real-time transport protocol (RTP), then the media trace packets are likewise 
configured to be sent using RTP. 4 Selvaggi describes using RTP traceroute packets configured, 
as much as possible, like conventional VoIP packets (which typically use RTP for the application 
protocol). However, read as a whole, amended claim 1 describes further operations that go well 



2 Selvaggi also mentions using an "rtp preserve" command. This appears to be a slight misspelling of "rtp 
reserve," which network command is used to tell nodes to establish a special queue for rtp packets. In effect, the 
nodes then set aside or "reserve" a portion of their throughput bandwidth for the handling of rtp packets (whether 
such rtp packets appear at the node or not). Both "rtp priority" and "rtp reserve," in any event, involve using 
network commands to specially configure the network nodes. 

3 In practice, the UDP ports conventionally associated with RTP packets, i.e., ports 16,384 to 32,767, are specified 
as arguments for this command, which is how the nodes distinguish the RTP packets from other packet types. 

4 More generally, other application protocols suitable for real-time streaming might be used, such as real-time 
streaming protocol or RTSP. 
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beyond Selvaggi's basic idea of matching, at a particular protocol level, the tracer packets to the 
media-carrying packets (which, in Selvaggi, involves matching application protocols and media 
payloads). In particular claim 1 describes how the "media trace" packets arc further configured 
to match, "at a protocol layer other than that of the application protocol," some service indicator 
to be used by the actual media payload packets. In other words, amended claim 1 recognizes the 
importance of matching the tracer packets to conventional media-carrying packets at more than 
just one protocol layer. Furthermore, claim 1 identifies this service indicator as "a priority 
indicator" to be provided by the actual media payload packets "to specify a desired one of a 
plurality of priority levels available in the network." The embodiment of amended claim 1 may 
thus be adapted to what might be termed a "full-service" network (not just a network that has 
been specially configured, as in Selvaggi) able to provide conventional media-carrying packets 
with a plurality of service or priority levels (not just one absolute service or priority level, as in 
the specially configured network of Selvaggi) depending on "the priority indicator" provided, at 
least at the start, by the actual media payload packets. 5 

In the claimed embodiment, the media-carrying packets are allowed to flexibly specify 
any one of "a plurality of priority levels" and are not just limited to being given absolute priority 
over other packet types, in the manner of Selvaggi. For example, in a multimedia conferencing 
context, each participant may be able to hear, see, and read text messages (including closed- 
captioning text) deriving from a particular speaker. In this example, which includes audio, 
video, and text data, the audio data may be given a somewhat higher throughput priority than the 
video data (so that the less important video data will be dropped first if network congestion 
makes packet dropping necessary). Also, the video data can be given a higher throughput 
priority than the text (unlike "real-time" audio and video data, it does not matter if the text data 
arrives on the participant's screen with a slight amount of delay). In this example, regardless of 
the media type to be used (audio, video, or text), the claimed "media trace packets" may be used 
to accurately analyze the media path for that particular media type. That is, in accordance with 
amended claim 1 , the media trace packets will be configured to match the priority indicator used 

5 The claimed "priority indicator," though required, by claim 1 to be at a protocol layer "other than that of the 
application protocol," may be provided at various other layers. For example, it may be provided in the form of 
Type of Service (TOS) or Differentiated Services Code Point (DSCP) bits at the Internet Protocol (IP) or internet 
layer. Alternatively, it may be provided in the form of Class of Service (COS) bits in an Ethernet Type II frame 
at the link layer (see applicant's original specification, page 5, second paragraph). Note also, this indicator may 
be varied from its start value, as by a network administrator manually balancing data flows, as the media packets 
proceed in hop-by-hop or node-by-node manner from the source host to destination host. 
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by that particular media type so that the network will provide those trace packets the same 
"desired one" of the "plurality of priority levels" that is specified for that media type. In short, 
the level of testing performed by the embodiment of amended claim 1 (e.g., which may be varied 
to match the different priority levels of different media types) is much finer-grained than the 
level of testing enabled by the disclosure of Selvaggi (e.g., which can only test the network at 
one priority level that is enforced for all media types, namely a single or absolute "RTP" priority 
level). 

For the foregoing reasons, then, the recited embodiment of amended claim 1 differs from 
that disclosed or suggested by Selvaggi both in the way it operates (e.g., the disclosed 
embodiment relies on specially configured "media trace" packets instead of the specially 
configured "performance nodes" of Selvaggi) and in the result it produces (e.g., finer-grained 
analysis of networks for different media types instead of enforcing a single "RTP" priority for all 
media types). Accordingly, amended claim 1 patentably defines over Selvaggi. 

Dependent claims 2-5 and 7-9 generally 

Insofar as claims 2-5 and 7-9 depend, directly or indirectly, from independent claim 1 and 
contain every limitation of that base claim, the above reasons supporting the patentability of 
claim 1 over Selvaggi apply with equal force to dependent claims 2-5 and 7-9. However, even 
independently of claim 1 , at least dependent claims 2, 5, and 8, as amended, separately define 
patentably over Selvaggi, as discussed below. 

Dependent claim 2 specifically 

When read together with independent claim 1, dependent claim 2 requires, inter alia, that 
the "media trace" packets be configured to use the same ("matching") DSCP bits as the "actual 
media payload" packets. Selvaggi fails to teach this feature. Instead, in order for Selvaggi's 
"RTP traceroute" (media trace) packets to be treated like conventional "VoIP" (actual media 
payload) packets, Selvaggi requires that the network nodes be configured to provide "rtp 
priority" service (see Selvaggi, par. 0075; see also footnote 4 hereinabove). That is, instead of 
specially configuring the media trace packets as dependent claim 2 recites, Selvaggi specially 
configures the network to be analyzed. While Selvaggi's approach is in accordance with 
Selvaggi's general concept of conforming the trace and actual media payload packets to a 
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common RTP standard, this approach is not in accordance with dependent claim 2, as amended. 
Accordingly, even independently of claim 1, dependent claim 2, as amended, patentably defines 
over Selvaggi. 



Dependent claim 5 specifically 

Dependent claim 5 has been rewritten to include the subject matter of f ormer claims 5 
and 6 and, accordingly, dependent claim 6 has been canceled. As amended, dependent claim 5 
requires that a member bit be set in the "media trace" packets that cause "the destination 
endpoint" (e.g., not just one of Selvaggi's "connecting nodes") to "immediately" generate "using 
a Real Time Control Protocol (RTCP)" (not, as is conventional for RTCP reports, based on a 
reporting interval that "scales linearly with the number" of media-receiving participants 6 ) a 
media path report for the "media trace" packets (not just for the "actual media payload" packets). 
Conversely, what Selvaggi describes, in paragraph 0051 as cited by the Action, is a "first 
endpoint" node that "knows" when a "second endpoint" node has been located when an error 
message is received from "a destination." This exactly describes a conventional traceroute 
operation in which an Internet Control Message Protocol (ICMP) error message (not an RTCP 
error message, as claimed) is returned, which ICMP message signals a "Destination 
Unreachable." 7 However, sending back an ICMP error message, as Selvaggi suggests, is 
different than forcing the destination to immediately generate an RTCP report, as recited by 
amended claim 5. In contrast to conventional RTCP reporting, the member bit of the 



6 Refer to RFC 3550, page 27, first paragraph. In conventional RTCP reporting, the reporting interval is 
dynamically calculated to increase as the number of participants increases. In a multicast context, for example, 
where each receiving participant is sending back a reception report to a shared intermediate node, these reports 
may be linearly combined at this node, so that the bandwidth needed between this intermediate node and the 
original source will linearly increase with the number of participants. Hence, in conventional RTCP reporting, 
the reporting interval is linearly increased with the number of participants to offset this effect so that the average 
bandwidth devoted to RTCP reporting is kept at a constant level. See RFC 3550, page 24, first paragraph. 

7 More specifically, in a conventional traceroute operation, invalid or "ephemeral" values (33,434 to 33,523) are 
selected for the "destination port" field in the UDP header, which values are incremented with each trace packet 
sent. Thus, when the trace packets finally reach the destination endpoint, the destination recognizes the port 
numbers as invalid and returns a Type 3/Code 3 ICMP message. This indicates a "destination unreachable/port 
unreachable" error. In Selvaggi, which uses "RTP traceroute" packets, and thus presumably includes destination 
port values that are valid for RTP (16,384 to 32,767), a Type 3, Code 1 ICMP message will be returned. Similar 
to conventional traceroute, this indicates a "destination unreachable" error, but differs by indicating a "host 
unreachable" error (Selvaggi's trace packets, because they carry a simulated VoIP media payload, are simply 
processed at the destination and hence are never returned to the source). In either event, an ICMP "destination 
unreachable" message is returned. Such ICMP messages may be contrasted with the Type 1 1/Code 0 or "time-to- 
live exceeded" ICMP error messages sent back by Selvaggi's connecting nodes, which is also described in 
Selvaggi's paragraph 005 1 . None of these ICMP messages constitute, as claimed, an RTCP type report. 
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embodiment of claim 5 causes the destination endpoint to "immediately" generate the media path 
analysis report. 8 Because the report may be immediately generated and returned, this allows a 
source to quickly pretest a network before sending, during a given session, actual media packets 
of a certain type. For these reasons, even independently of claim 1 , dependent claim 5, as 
amended, patentably defines over Selvaggi. 



Dependent Claim 8 specifically 

In the Action of May 22, 2008, the examiner notes that Selvaggi fails to show the "media 
trace" packets being caused to play out low volume noise by inserting the noise into these 
packets "before" they are sent along the media path. However, the examiner relies on Alberth 
(par. 0002) to suggest inserting comfort noise before packet transmission "to avoid annoying the 
listener." 

Referring to par. 0014 of Alberth, what Alberth actually teaches is inserting intelligible 
"comfort noise" (not "low-volume noise," as recited 10 ) to give the "local" user notice that the 
"call is [still] in process." Conventionally, one of ordinary skill would have been disinclined to 
add the comfort noise to the "media trace" packets, at least at the point of sending, because trace 
packets so modified would have consumed extra network bandwidth each time they were sent. 11 
In other words, comfort noise is added by a receiving endpoint before playout. However, 
applicants recognized there is an advantage to inserting "noise" into the trace packets, even 
"before" these packets are sent along the media path, insofar as such approach may be used to 
create uniformly-sized trace packets suitable for thwarting "traffic analysis" attacks by malicious 



8 See applicant's original specification, page 14, fourth paragraph and also page 15, first paragraph. Compare to 
conventional RTCP reporting as discussed in footnote 8. Note that Selvaggi does not specify how quickly its 
error report, regardless of its type, is generated. 

9 E.g., see applicant's original specification, page 9, paragraph 3 and original claim 7. 

10 Alberth distinguishes between white noise, which type of "comfort noise is not ...intelligible" (par. 0002) and 
"non-noise," which type "refers to audio that is intelligible" (par. 0015). Albert favors the latter type so that, for 
example, the comfort noise may be easily distinguished, when "low," from "the sounds of a dropped call" (par. 
0002). In this regard, Alberth teaches directly away from claim 8's recited use of "low- volume noise." 

1 1 Once these trace packets reached their destination, one of ordinary skill might have considered modifying these 
packets at that point to include "low-volume noise" to "avoid annoying listeners" (this, in fact, is the approach 
suggested in Barrack, et al., U.S. Pat. App. Pub. No. 20040008715, which was cited against claim 8 in the 
previous Action dated Dec. 21, 2007). However, so modifying the trace packets does not comport with claim 8's 
recited limitation of inserting the noise "before" the trace packets are sent along the media path. 
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outsiders. 12 Thus combining the teachings of Alberth, which truly apply only to "actual media 
payload" packets, to those of Selvaggi fail to make apparent or obvious the combination recited 
by dependent claim 8. 

Independent claims 21 and 30 

Independent claim 21 is directed to a system comprised of "means for" elements that 
perform operations for analyzing a media path in a packet switched network. Independent claim 
30 is directed to a computer readable medium performing operations for analyzing a like media 
path. Both of these independent claims have been amended to include features that are at least 
similar to the features of independent claim 1. Accordingly, claims 21 and 30 should be allowed 
for at least similar reasons as claim 1 . 

Dependent claims 22-25 and 27-29 generally and claims 22. 25, and 28, specifically 

Claims 22-25 and 27-29 depend, directly or indirectly, from independent claim 21, and 
thus should be allowed for at least the same reasons. 

Dependent claims 31-34 and 36-38 generally and claims 31, 34, and 37, specifically 

Claims 31-34 and 36-38 depend, directly or indirectly, from independent claim 30, and 
thus should be allowed for at least the same reasons. 



12 See applicant's original specification, page 23, lines 14-15. See also the Background section of the 

corresponding parent application, U.S. Pat. App. Ser. No. 10/723,118. 
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CONCLUSION 

For the foregoing reasons, the applicants request reconsideration and allowance of claims 
1-5, 7-9, 21-25, 27-34, and 36-38. The applicants encourage the examiner to telephone the 
undersigned if it appears that an interview would be helpful in advancing the case. 

Customer No. 73552 

Respectfully submitted, 




STOLOWITZ FORD COWGER LLP 
621 SW Morrison Street, Suite 600 
Portland, OR 97205 
(503) 224-2170 
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